在绝大多数情况下，当我们说一行文字“一字千金”时，往往只是在用夸张的方式表达其内容具备极高的价值。
但在某些特殊时候，“一字千金”这个词很可能真的变成它字面上的那个意思。2月25日，上海市一家港股上市企业微盟发布公告，称“其一名运维人员贺某因个人精神、生活等原因”而对企业的数据库进行了恶意破坏，直接导致这家公司的线上系统引发了全面故障。
虽然引发这一切的那名运维人员贺某，现在已经被宝山区的公安民警抓获，但这波闹剧引发的损失却是已经难以挽回。
作为一家上市企业，这家倒霉公司从23日晚上系统开始故障之后，资本市场就迅速对其做出了反应。最直观的体现就是在他们的股价上，仅仅在2月24日一天之内，微盟就直接蒸发掉了12.53亿港元的市值。
一行业内流传的删库代码只有“rm -rf/*”区区几个字符，而当前港元兑人民币的汇率差不多是1：1，黄金的当前市价又是在340元人民币/克。
有数学好的学习委员可以来算一下，这位程序员老哥写下的这行代码平均一个字符到底值多少黄金（手动滑稽）。股价的下跌还只是明面上的损失，至于其他隐性损失则更是难以估量。这里先给大伙简单科普一下微盟这家企业的大体业务吧，他们是一家给线上的小程序电商提供系统支持服务的企业。用他们的专业术语来说叫“智能商业服务提供商”，不过我们大可以简单的将其理解为给微信上的小程序电商提供服务的一个平台，或者说就是微信上的淘宝（当然这么说并不算严谨，只是为了方便理解）。想象一下，如果你是一个在某宝上开网店的个体商户，现在某宝的系统崩溃了，那么你将会面临的情况基本上就和本次事件里微盟商户的遭遇差不多了。
现在微盟在这里演了出自摆乌龙的大戏，那么他的友商自然会跑过来强（趁）势（火）围（打）观（劫）一波。2月25日，有赞发出“江湖救急”公告，称愿意为所有因为微盟本次删库事件而业务停摆的商户，提供长达两周的免费开店业务，用意是帮助他们度过这个特殊时期。也许是怕自己挖墙脚的意图不够明显，他们还特地为那些“在微盟的软件服务尚未到期”的商户准备了额外的特殊补贴……
用小脑想想也能明白，只要有赞那边别过两天也出个类似的数据库被删事故，那么在两周的免费体验期过后，这些商户基本上不太可能再主动回归微盟了。不过商业竞争嘛，这种事倒也还算可以理解……只要别最后查出来微盟那个删库跑路的运维，竟然是有赞派过去的就行。说起来，相比起这次的苦主微盟，有赞这家企业在圈外的名气应该还要更大一些。
毕竟他们家的CEO白鸦，曾经因为在公司年会上公然宣称996工作制度，以至于被众多网友骂上了热搜，最后还被杭州有关部门的执法人员约谈过。
啧啧……总感觉那些个体小商户怕不是又跳进了另外一个火坑里哦~
话说回来，其实运维（DBA）删库跑路现象在IT圈子里其实不算什么太稀罕的事情，几乎每年都会有类似的新闻传出。只不过微盟这一次的损失特别惨重，创造了因为删库而一天蒸发十亿市值的纪录，所以才得到了这么高的舆论关注度。打个未必恰当的比方，就好像说世界上被戴绿帽的苦主千千万，但是能够被全国人民一起吃瓜关注的也就那几位一样。（我没说宝强哥啊，你们别瞎想）就像那些给自家老公戴绿帽的姑娘各有各的理由一样，历年来各位做出删库跑路这种壮举的运维大兄弟，他们的初衷也可以称得上是千奇百怪。
2018年9月，顺丰某高级工程师在升级系统数据库的时候就一时不慎，将RUSS 数据库顺手给删了，导致了整个顺丰集团的线上发车功能都陷入了长时间停摆。
这件事的处理结果非常简单，顺丰在把这位直接责任人揪出后，直接将其当场开除了事。
这起事件一度还在程序员圈子里引起了热议，认为顺丰此举有待商榷。毕竟一个能让员工在无意间的误操作而造成严重后果的数据库，其本身的安全性就是存在问题的，不能把责任完全归咎于员工个人。同样因为手滑而酿成大错的还有海外的某明星企业GitLab，作为全球第二大的开源代码托管平台，GitLab的技术实力与他的名气似乎并不相称。2017年1月31日，GitLab内部的一位系统管理员在给数据库做日常维护时，遭受到了外部的恶意 DDoS 攻击。虽然该管理员成功阻止了本次攻击，但他却在做事后的修复工作时一时不慎，在生产环境上执行了数据库目录删除命令……大家可以直接理解为简单的三个字“格式化”。
sudo rm -rf
最终经过一番抢救性的数据修复，论坛上原本高达300GB的数据只保留下来 4.5G，基本上是十不存一，直接导致当时的GitLab被迫下线。
虽然造成运维删库跑路的最主要原因都是手滑，但是并不代表就没有发生过员工为了报复公司而做出的有意之举。
2017年6月，荷兰海牙的一家云主机商 verelox.com，就被一名与企业存在纠纷的前任管理员删光了公司所有客户的数据，最终导致企业整体被迫下线。2018年，杭州市余杭区人民法院又宣判过一起因为删库引发的案件，被告人甚至都不知是简单的运维员工，而是作为原告的那家科技企业的前技术总监。具体过程当然无非就算那点狗屁倒灶的破事，因为公司发展不景气、新人换旧人、内部派系斗争等原因，从2014年加入这家企业一手搭建起内部系统的技术总监被公司老板强行清退。而对此大感不满的这位前技术总监，则直接来了个冲冠一怒，把老东家的数据库与服务器来了个大扫除，最后被人民法院判了2年半的刑期。
所以说目前针对运维删库跑路现象的讨论，其实都有点纸上谈兵的意思。
不管是设置备份、分级权限操作还是多重审核之类的机制，归根结底也只能用来降低因为“员工手滑”而导致的无心之过。如果碰上的是因为对公司不满而打算鱼死网破的内部员工，那么再严密的防范机制也还是可以被人绕过去的。就像杭州那家科技企业的例子，人自个就是你们家技术部门的最高领导，他铁了心要把公司的数据库删了跑路，你就是备份做的再好，也无非是让人家多费两道手，多删除覆盖几遍罢了。
唯一能从根本上解决问题的方法，其实还是在公司老板自己身上，对员工好点（多给点钱）其实啥事都解决了。钱给足了，招点经验丰富的靠谱员工，“手滑”的风险自然也就小了；至于员工恶意报复……你钱都给足了，哪来那么多想不开的非要拼着自己进去蹲大狱，也要来给你找这个不痛快？
主笔 | 阿虚
编辑 | 四少
本文特约首发于网易新闻·网易号
未经允许，不得转载
▼延伸阅读▼